Collection of Internet/Collection of Internet.iso/infosrvr/dev/www_talk.930/[e-mail] _Tue Dec 1 18:28:35 1992.msg

Internet Message Format | 1994-01-24 | 6KB

Return-Path: <[e-mail]>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA01687; Tue, 1 Dec 92 18:28:35 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
    id AA23023; Tue, 1 Dec 1992 18:41:41 +0100
Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
    id AA13710; Tue, 1 Dec 92 11:41:38 -0600
Received: from localhost by pixel.convex.com (5.64/1.28)
    id AA22962; Tue, 1 Dec 92 11:41:34 -0600
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail] (Jim Whitescarver), [e-mail]
Subject: Re: The <PRE> tag
In-Reply-To: Your message of "Tue, 01 Dec 92 16:41:19 +0100."
             <[e-mail]>
Date: Tue, 01 Dec 92 11:41:34 CST
From: Dan Connolly <[e-mail]>


>Perhaps we should have all three.

>I understand that these are the only SGML-conformant combinations.  Is
>this too much of a mess?

I think so. The processing should be broken into two parts: SGML parsing,
and application processing. The significance of newlines is an application
issue: the SGML parser never throws out newlines in data (it does throw
out newlines between tags and in some other places that I don't fully
understand).

These are the choices for SGML parsing:

    CDATA        all characters treated as data.
            Terminated by </A where A is any letter.
    RCDATA        characters and entities only. &entity; recognized.
            Terminated by </A as above
    mixed content    tags and #PCDATA.
            Tags, entity references, comments, etc. recognized.
            The pattern of tags and data is regulated
            by the element declaration.
    element content    tags only. Pattern of tags is regulated.
    ANY        like mixed content, but tags aren't regulated

CDATA is simplest to process, but you can't do things like

    char* any_string;
    printf("<XMP>%s</XMP>", any_string);

because any_string might contain </A, and you're screwed.

RCDATA is capable of the above construct, but at a cost:

    char* any_string;
    char* rcdata = HTML_replace_specials(any_string);
    printf("<XMP>%s</XMP>", rcdata);
    free(rcdata);

where HTML_replace_specials changes '<' to < (to prevent </A), '>' to >
(to prevent ]]>, the marked-section close delimiter. Ugh!), and
'&' to & (to prevent &xxx from being mistaken for an entity reference).

But if you're going to go to that trouble, you might as well
use mixed content. That's why I changed my mind about using RCDATA
for XMP and LISTING elements.

My current DTD only uses element content (for the HTML document element*),
CDATA (for XMP and LISTING) and mixed content (for everything else).

As to your suggestions...

><XMP>        newlines significant        no anchors    CDATA

This is already supported, except that most implementations don't
quite parse CDATA correctly. The "newlines significant" isn't a
parsing issue. It's an issue of how the application processes character
data. Let's call this mode of application processing where the
characters are written to the screen as-is, rather than
typeset into paragraphs TYPEWRITER mode. We'll call the default TYPESET mode.

><PRE>        newlines significant        no anchors    RCDATA

The only implementation of the PRE tag that I know of looks more like:

<PRE>        newlines significant        anchors        PCDATA

It's actually pretty clean: you use
mixed content SGML parsing, and TYPEWRITER application processing.
So I changed the name to TYPEWRITER, for no good reason, really.

The newlines significant/no anchors/RCDATA is what I suggested for
XMP and LISTING, so they could contain any string. But since current
implementations don't process entities in these elements, it's
not worth it.

><FIXED>        newlines not significant     anchors        PCDATA

This introduces a third application mode besides RAW and TYPESET:
it's kinda like RAW, but you toss the newlines, and start a newline
at every <P> tag. I don't like it.

>Tony, can you make a similar patch for <fixed> as above for Midas?

You could, but it doesn't fit neatly into the current architecture.
Tony wrote one widget to do TYPESET processing (SGMLCompoundText)
and one to do TYPEWRITER processing (SGMLPlainText). The FIXED
widget calls for a new widget, or a modification of SGMLPlainText
to ignore newlines in some cases. (You can't just use the SGMLCompoundText
with a fixed-width font, because it compresses whitespace.)

>I have put Dan's new spec (which contains <typewriter> -- what's going on,
>Dan?!) in the web at
>http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/MarkUp.html with a link from
>the current spec.

Thanks.

>  The DTD was not in the tar file, so Dan's previous one is
>linked in. This includes all Dan's test HTML.

Ack! I think the DTD is pretty important. I'll get the new
one there ASAP. I highly suggest that _all_ data providers grab the DTD
and the sgmls parser and try validating samples of the data they're
serving up. It's the quickest and surest way to check for compliance.
I need to write a section for data providers in the spec.

>I would like to include <HEADER> and <BODY> tags too.

* I wrestled with this at great length to come up with a DTD
lends _some_ structure to HTML wihthout clashing badly with
existing data.

The document element declaration is:
<!ELEMENT HTML O O  ((TITLE? & NEXTID? & ISINDEX?), BODY)>

The O O means the HTML start and end tags can be omitted.
They'll be inferred by the parser. Since there's no #PCDATA
in the content model, it has element content, so that
whitespace between tags is thrown out.

The TITLE, NEXTID, and ISINDEX can come in any order, and
they can are optional, but they can appear at most once,
and they have to be before the BODY.

I made the <BODY> tags minimizable so current
HTML is legal. I couldn't seem to work in a HEADER
element the same way.

Dan